In any system a deadlock occurs when two or more applications are waiting on a resource that the other application holds. In such a situation, neither will be able to proceed and neither will relinquish their locked resources voluntarily. In such cases, typically deadlock detector mechanism are used, where the system is periodically monitoring for deadlocks, and if a deadlock occurs, one of the transactions is terminated thereby causing that transaction to release its locks so that the other application can proceed.
In recent times, multithreaded processing has become a common feature facilitating optimal utilization of processor resources. Operating systems that support multithreaded processing typically include a scheduler for coordinating the processing of multiple threads. A computer system executing a multithreaded computer program often includes shared resources, such as program objects, to which more than one thread seek access, which can lead to deadlocks To address this conflict, many shared resources are capable of being locked by a thread, preventing other threads from accessing the resources while the resources remain in the locked state. Two or more threads may include a certain sequence of locks and unlocks upon shared resources that, if executed in a particular sequence relative to each other, could result in a deadlock.
Techniques exist to decide which transaction may be permitted to continue and which transaction shall be aborted in case such a deadlock occurs. Normally, in resolving such deadlock transaction, those transactions having higher priorities are given precedence over transactions having a lower priority.
Currently, methods exist to obtain the entire transaction data of computer applications that result in deadlocks. The transaction data includes all or a large section of the code executed in each of the transactions until the occurrence of a deadlock. Such transaction data is presently available to application developers to determine specific lines of code responsible for causing the deadlock. While this information is useful, multitude of industry-standard applications have large code bases and these code bases access vast number of tables and code-paths that further access the resources. Given this complex application code base, pinpointing a specific line of source code for each thread/application that caused a deadlock can be difficult and time consuming.